Inventor(s): Frutuoso et al. 
Appl. Ser. No.: 09/365,066 
Atty. Dkt. No.: 5053-23300 

Amendments to the Claims: 

Please cancel claims 5, 28, and 63-70 without prejudice. 
The following lists all claims and their status. 



1. (Currently amended): A method for processing receiving trading partner transactions 
comprising: 

receiving at least one incoming transaction from at least one sending trading partner, 
wherein r e ceiving at l e ast one incoming transaction from at least one sending trading 
partner comprises receiving at least incoming transaction from at least one sending 
trading partner through an industry clearinghous e system ; 

translating at l e ast on e incoming transaction from a first data format to a second data 
format, wherein th e first data format comprises a data format of an industry cl e aringhouse 
syst e m ; 

automatically reading additional information from an administration system in data 
communication with a computer system, wherein the additional information is read in 
response to receiving at least one incoming transaction from the at least one sending 
trading partner, and wherein the additional information is identified by at least one 
business rule; 

generating at least one outgoing transaction in response to reading the additional 
information from the administration system , wherein at least one outgoing transaction 
comprises data from the incoming transaction and the additional information read from 
the administration system ; and 




translating at least one outgoing transaction into a format readable by a receiving trading 
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partner; and 

sending at least one outgoing transaction to at least one receiving trading partner. 

2. (Previously presented): The method of claim 1, wherein at least one business rule comprises 
one or more keywords. 

3. (Previously presented): The method of claim 1, wherein at least one business rule comprises 
one or more logical operators. 

4. (Previously presented): The method of claim 1, wherein at least one business rule comprises a 
string of at least one keyword and at least one operator, and wherein at least one business rule is 
entered into a computer system by a user via a user interface. 



6. (Previously presented): The method of claim 1, wherein the reading additional information 
from the administration system in response to receiving at least one incoming transaction from 
the at least one sending trading partner further comprises: extracting the additional information 
from the administration system according to search criteria. 

7. (Original): The method of claim 6, wherein the search criteria comprise one or more 
keywords. 

8. (Previously presented): The method of claim 1, further comprising: queuing at least one 
outgoing transaction in response to generating at least one outgoing transaction. 



10. (Previously presented): The method of claim 1, wherein sending at least one outgoing 




(CancelL 





(Cancelled) 
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transaction to at least one receiving trading partner further comprises sending at least one 
outgoing transaction to at least one receiving trading partner through an industry clearinghouse 
system. 



12. (Previously presented): The method of claim 1, wherein at least one incoming transaction is 
an insurance-related transaction. 

13. (Currently amended): A system comprising: 

a CPU; 

a database coupled to the CPU; 

an administration system coupled to the CPU; and 

a memory coupled to the CPU, wherein the memory stores one or more computer 
programs executable by the CPU; wherein the computer programs are executable to: 



store a trading relationship between trading partners of a transaction, wherein the 
trading relationship is stored in the database, wherein at least one trading partner 
is a sending trading partner and at least one trading partner is a receiving trading 
partner; 

receive at least one incoming transaction from the at least one sending trading 
partne r, wherein at l e ast one incoming transaction is received from at lea s t one 
sending trading partner through an industry cl e aringhous e syst e m ; 

translate at l e ast one incoming transaction from a first data format to a second data 
format, wherein th e first data format comprises a data format of an indu s try 




(Cancelled) 
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clearinghous e system; 

automatically read additional information from the administration system in 
response to receiving at least one incoming transaction from at least one sending 
trading partner, wherein the additional information is identified by at least one 
business rule; 

generate at least one outgoing transaction in response to reading the additional 
information from the administration syste m, wherein at least one outgoing 
transaction comprises data from the incoming transaction and the additional 
information read from the administrative system ; 

translate at least one outgoing transaction into a format readable by a receiving 
trading partner; and 

send at least one outgoing transaction to at least one receiving trading partner, 
wherein at least one receiving trading partner is identified in the trading 
relationship. 



14. (Previously presented): The system of claim 13, wherein at least one business rule 
comprises a string of at least one keyword and at least one operator, and wherein at least one 
business rule is entered into a computer system by a user via a user interface. 

15. (Previously presented): The system of claim 13, wherein at least one business rule is defined 
by a user through a user interface. 



17. (Previously presented): The system of claim 13, wherein at least one incoming transaction is 
an insurance-related transaction. 




(Cancelled) 
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18. (Currently amended): A carrier medium, which stores program instructions, wherein the 
program instructions are executable by a computer system to implement the method of: 

receiving at least one incoming transaction from at least one sending trading partner, 
wherein receiving at least one incoming transaction from at least on e sending trading 
partner compris e s receiving at least incoming transaction from at least one sending 
trading partn e r through an industry clearinghouse system; 

translating at l e ast on e incoming transaction from a first data format to a second data 
format, wherein the first data format comprises a data format of an industry clearinghouse 
system; 

reading additional information from an administration system in response to receiving the 
incoming transaction from the at least one sending trading partner, wherein the additional 
information is identified by at least one business rule; 

automatically generating at least one outgoing transaction in response to reading the 
additional information from the administration system , wherein at least one outgoing 
transaction comprises data from the incoming transaction and at least a portion of the 
additional information read from the administrative system ; 

translating at least one outgoing transaction into a format readable by a receiving trading 
partner; and 

sending at least one outgoing transaction to at least one receiving trading partner. 

19. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
comprises one or more keywords. 
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20. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
comprises one or more logical operators. 

21. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
comprises a string of at least one keyword and at least one operator, and wherein at least one 
business rule is entered into the computer system by a user via a user interface. 

22. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
is stored in a database. 

23. (Previously presented): The carrier medium of claim 18, wherein the administration system 
from which additional information is read is specified by a map, wherein the map comprises a 
relationship between at least one outgoing transaction and a source for the additional 
information. 

24. (Original): The carrier medium of claim 23, wherein the map is specified by a user through 
a user interface. 

25. (Currently amended): The carrier medium of claim 23, wherein the program instructions are 
further executable by the computer system to implement generating the map, wherein generating 
the map comprises: 

selecting one or more source fields, wherein each source field corresponds to the source 
for the additional information; and 

selecting a destination field, wherein each destination field corresponds to at least one 
outgoing transaction. 

26. (Original): The carrier medium of claim 25, wherein a value of the destination field is a sum 
of respective values of the one or more selected source fields. 

27. (Original): The carrier medium of claim 25, wherein the program instructions are further 
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executable by the computer system to implement generating a value of the destination field as a 
function of the one or more source fields. 



29. (Previously presented): The carrier medium of claim 18, wherein the program instructions 
are further executable by the computer system to implement storing a schedule in memory, 
wherein the schedule relates to at least one incoming transaction, and wherein the schedule 
comprises a predetermined time for receiving at least one incoming transaction from the at least 
one sending trading partner. 

30. (Previously presented): The carrier medium of claim 18, wherein the program instructions 
are further executable by the computer system to implement storing a schedule in memory, 
wherein the schedule relates to at least one incoming transaction, and wherein the schedule 
comprises a predetermined time for reading the additional information from the administration 
system. 

31. (Previously presented): The carrier medium of claim 18, wherein the program instructions 
are further executable by the computer system to implement storing a schedule in memory, 
wherein the schedule relates to at least one outgoing transaction, and wherein the schedule 
comprises a predetermined time for sending at least one outgoing transaction to the at least one 
receiving trading partner. 

32. (Previously presented): The carrier medium of claim 18, wherein reading additional 
information from the administration system in response to receiving at least one incoming 
transaction from at least one sending trading partner further comprises extracting the additional 
information from the administration system according to search criteria. 

33. (Original): The carrier medium of claim 32, wherein the search criteria comprise one or 
more keywords. 




(Cancelled) 
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34. (Previously presented): The carrier medium of claim 18, wherein the program instructions 
are further executable by the computer system to implement queuing at least one outgoing 
transaction in response to generating at least one outgoing transaction. 



36. (Previously presented): The carrier medium of claim 18, wherein at least one outgoing 
transaction is sent to the at least one receiving trading partner through an industry clearinghouse. 



38. (Previously presented): The carrier medium of claim 18, wherein at least one incoming 
transaction is an insurance-related transaction. 

39. (Previously presented): The carrier medium of claim 18, wherein at least one outgoing 
transaction is an insurance-related transaction. 

40. (Previously presented): The carrier medium of claim 18, wherein at least one outgoing 
transaction is an annuity asset pricing transaction. 

41. (Previously presented): The carrier medium of claim 18, wherein at least one outgoing 
transaction is a positions and valuation focused refresh transaction. 

42. (Previously presented): The carrier medium of claim 18, wherein at least one outgoing 
transaction is a positions and valuation full refresh transaction. 

43. (Previously presented): The carrier medium of claim 18, wherein at least one outgoing 
transaction is an insurance pricing transaction. 




. (Cancelled) 





. (Cancelled) 
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44. (Previously presented): The carrier medium of claim 18, wherein at least one outgoing 
transaction is a commission settlement transaction. 

45. (Previously presented): The carrier medium of claim 18, wherein at least one sending 
trading partner is the receiving trading partner. 

46. (Original): The carrier medium of claim 18, wherein the carrier medium is a memory 
medium. 

47. (Currently amended): A carrier medium, which stores program instructions, wherein the 
program instructions are executable by a computer system to implement the method of: 

storing a trading relationship between trading partners of a transaction, wherein at least 
one trading partner is a sending trading partner and at least one trading partner is a 
receiving trading partner; 

receiving at least one incoming transaction from at least one sending trading partner, 
wherein r e ceiving at least one incoming transaction from at least on e s e nding trading 
partner comprises receiving at l e a s t incoming transaction from at least one sending 
trading partner through an industry clearinghouse system; 

translating at least one incoming transaction from a first data format to a s e cond data 
format, wh e rein the first data format comprise s a data format of an industry clearinghouse 
system; 

reading additional information from an administration system in response to receiving the 
incoming transaction from the at least one sending trading partner, wherein the additional 
information obtained is identified by at least one business rule; 

automatically g enerating at least one outgoing transaction in response to reading 



10 



Inventor(s): Frutuoso et al. 
Appl. Ser. No.: 09/365,066 
Atty. Dkt. No.: 5053-23300 

additional information from the administration system , wherein at least one outgoing 
transaction comprises data from the incoming transaction and the additional information 
read from the administrative system ; 

translating at least one outgoing transaction into a format readable by a receiving trading 
partner; and 

sending at least one outgoing transaction to the at least one receiving trading partner, 
wherein the at least one receiving trading partner is identified in the trading relationship. 

48. (Previously presented): The carrier medium of claim 47, wherein at least one business rule 
comprises a string of at least one keyword and at least one operator, and wherein at least one 
business rule is entered into the computer system by a user via a user interface. 

49. (Previously presented): The carrier medium of claim 47, wherein at least one business rule 
is stored in a database. 

50. (Previously presented): The carrier medium of claim 47, wherein at least one outgoing 
transaction is an insurance-related transaction. 

51. (Original): The carrier medium of claim 47, wherein the carrier medium is a memory 
medium. 

52. (Previously presented): The method of claim 1, wherein at least one business rule comprises 
a receiving trading partner identifier. 

53. (Previously presented): The method of claim 1, wherein at least one business rule comprises 
an administration system identifier. 

54. (Previously presented): The method of claim 1, wherein at least one business rule comprises 
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a transaction identifier. 



55. (Previously presented): The method of claim 1, wherein at least one business rule comprises 
a transaction status. 

56. (Previously presented): The method of claim 1, wherein at least one business rule comprises 
a sending trading partner identifier. 

57. (Previously presented): The method of claim 1, wherein at least one business rule is entered 
into a database. 

58. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
comprises a receiving trading partner identifier. 

59. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
comprises an administration system identifier. 

60. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
comprises a transaction identifier. 

61. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
comprises a transaction status. 

62. (Previously presented): The carrier medium of claim 18, wherein at least one business rule 
comprises a sending trading partner identifier. 



63. (Cancelled) 

64. (Cancelled) 
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65. (Cancelled) 

66. (Cancelled) 

67. (Cancelled) 

68. (Cancelled) 

69. (Cancelled) 

70. (Cancelled) 
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Response to Office Action Mailed June 18, 2003 

A. Pending Claims 

Claims 1-4, 6-8, 10, 12-15, 17-27, 29-34, 36, 38-62 are currently pending. Claims 5, 28, 
and 63-70 have been cancelled. Claims 1, 13, 18, 25, and 47 have been amended. The claims 
have been amended for clarification and/or correction of typographical errors. 

B. The Claims Are Not Obvious Over Borghesi In View of DeRienzo and Further In 
View of Richards Pursuant To 35 U.S.C. § 103(a) 

The Examiner rejected claims 1-8, 10, 12-15, 17-28, 32-34, 36, and 38-70 under 35 
U.S.C. 103(a) as obvious over U.S. Patent No. 5,950,169 to Borghesi et al. (hereinafter 
"Borghesi") in view of U.S. Patent No. 6,003,007 to DiRienzo (hereinafter "DiRienzo") and 
further in view of U.S. Patent No. 6,408,303 to Richards (hereinafter "Richards"). Applicant 
respectfully disagrees with these rejections. 

In order to reject a claim as obvious, the Examiner has the burden of establishing a prima 
facie case of obviousness. In re Warner etal, 379F.2d 1011, 154U.S.P.Q. 173, 177-178 
(C.C.P.A. 1967). To establish a prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 981, 180 U.S.P.Q. 
580 (C.C.P.A. 1974), MPEP § 2143.03. 

Amended claim 1 includes the features of: 

receiving at least one incoming transaction from at least one sending trading partner; 

automatically reading additional information from an administration system in data 
communication with a computer system, wherein the additional information is read in 
response to receiving at least one incoming transaction from the at least one sending 
trading partner, and wherein the additional information is identified by at least one 
business rule; 
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generating at least one outgoing transaction in response to reading the additional 
information from the administration system, wherein at least one outgoing transaction 
comprises data from the incoming transaction and the additional information read from 
the administration system; 

translating at least one outgoing transaction into a format readable by a receiving trading 
partner; and 

sending at least one outgoing transaction to at least one receiving trading partner. 

Support for the amendments to claim 1 can be found, for example, in originally filed claim 5. 
Further support for the amendments to claim 1 can be found, for example, in Applicant's 
specification, which states: 

An outgoing transaction is generated in response to obtaining additional 
information from an administration system. The outgoing transaction may include 
the additional data obtained from the administration system. The outgoing 
transaction is sent to the at least one receiving trading partner. The sending of 
outgoing transactions may take place according to a schedule which may specify a 
date and time or a frequency at which outgoing transactions are to be sent. The 
outgoing transaction may be queued for sending along with other outgoing 
transactions. The outgoing transaction may be reformatted into an industry 
standard data format by an adapter. 
(Specification, page 22, lines 23-31) 

Applicant's claims are directed to a method of facilitating the processing of electronic 
transactions between a sending trading partner and a receiving trading partner. In order for a 
sending trading partner to perform a transaction electronically with a receiving trading partner, 
both the sending and receiving trading partners have typically needed to follow standards for the 
format and transmission of electronic data. The use of standards, however, may create problems 
for the trading partners, as noted in Applicant's specification, which states: 

The adherence of trading partners to industry standard data formats is not enough 
to automate all transactions. Existing approaches often require the intervention of 
a skilled computer programmer for certain tasks and transactions. For example, in 
order to process a transaction such as a commission payment request received 
electronically from a broker/dealer, an insurance carrier often must write, test, and 
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install a custom program in a programming language such as COBOL to tell its 
payment system to obtain the necessary broker-related information from another 
source, such as a particular database. This approach towards EDI tends to be 
wasteful, time-consuming, and expensive. 

For at least the foregoing reasons, there is a need for an improved system and 
method for processing transactions in a more efficient manner. 
(Specification, page 3, lines 2-13) 

Applicant's claimed method overcomes these problems by providing a method for trading 
partners to send transactions to each other for processing. Applicant overcomes the difficulties 
of trading between partners by providing a method of taking information regarding a transaction 
from a sending trading partner, automatically processing the information to place the transaction 
in a format that can be processed by the receiving partner, and sending the information to the 
receiving partner. For example, Applicant's specification states: 

The present invention provides various embodiments of a method and system for 
automating data exchange processing. In one embodiment, a trading relationship 
between trading partners is stored in a trading relationship database. 
At least one trading partner is a sending trading partner and at least one trading 
partner is a receiving trading partner with respect to a transaction between the at 
least one sending trading partner and the at least one receiving trading partner. 
Maps and business rules may also be defined and stored with regard to particular 
types of transactions and particular trading partners. Maps define sources of 
additional data used to process a transaction, such as fields within an 
administration system. 

In response to receiving the incoming transaction from the at least one sending 
trading partner, additional information may be read from an administration system 
in order to complete the processing of the transaction. 

An outgoing transaction is generated in response to obtaining additional 
information from an administration system. The outgoing transaction may include 
the additional data obtained from the administration system. The outgoing 
transaction is sent to the at least one receiving trading partner. 
The outgoing transaction may be reformatted into an industry standard data format 
by an adapter. 



The Examiner states: 

Regarding claim 1, Borghesi discloses a method for processing receiving 
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trading partner transactions comprising: 

receiving at least one incoming transaction from at least one sending 

trading partner (column 16, lines 4-10);... 

reading additional information .... (column. 12, linesl4-58) 

sending at least one outgoing transaction to at least one receiving trading 

partner (column 16, lines 46-49). 

Applicant disagrees with the Examiner's interpretation of Borghesi. 

Applicant submits that Borghesi appears to address some of the same problems that are 
described in Applicant's specification. For example, Borghesi states: 

The various available methods and systems for generating insurance costs and 
estimates are typically further limited to individual discrete calculations. After an 
appraiser prepares an estimate for repairing a vehicle, a separate calculation is 
often completed through a separate computer program to compute total loss 
valuation of a vehicle. Although these individual calculations may be obtained 
through separate programs, the results of each of the programs are difficult or 
awkward to compare because of the separate programs and datafiles involved. 

Similarly, although separate methods and systems for performing some of the 
administrative tasks in insurance claim processing workflow are available, each of 
these separate computer programs requires certain types of data and each outputs a 
certain type of data. The data required for the separate programs may overlap and 
lead to redundant data entry tasks being performed. Data sharing between the 
different, discrete methods and systems that an insurance company uses may be 
difficult due to incompatible data formats. Therefore, an insurance claim adjuster 
must spend time keeping track of, and running, the separate programs. Appraisers, 
repair shops, and others involved in claim processing often need to switch 
between, and learn how to operate, separate software programs having separate 
data and interface requirements. Present methods of handling insurance claims not 
only tend to require the use of separate software and hardware tools for various 
calculations, but also require separate organization of administrative material and 
client mailings to the insured party. Insurance companies often juggle many 
separate computer files and pieces of paper generated for each claim. 
(Borghesi, col. 1, line 56 - col. 2, line 19) 

Borghesi solution to the identified problems differs from Applicant's approach. Borghesi states: 
One advantage of the presently preferred embodiment is that a single user, who 
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previously had to master and juggle numerous programs and pieces of paper, may 
accomplish all the necessary insurance processing tasks using a single program 
that holds all claim information in a file in a single database. Other advantages, 
stemming from the common graphic user interface and single insurance claim 
workfile, are the elimination of redundant data entry and the ability to view 
separate calculations at the same time. Further, the entire administrative 
management of claim processing is aided through the preferred event log section 
of the insurance claim datafile. 
(Borghesi, col. 3, lines 18-29) 

Borghesi appears to teach the use of a single software program, which all parties needing to make 
transactions would use. Unlike Applicant's claimed method, Borghesi appears to teach that the 
parties undertaking a transaction use the same software to access a common datafile. For 
example, Borghesi states: 

The system includes at least one remote computer, a mainframe computer (or 
server), and a network connecting the computers wherein an insurance claim 
datafile containing information pertinent to a particular claim may be transferred, 
accessed and processed by authorized parties. A common graphic user interface 
allows users to manage claims workflow, including the performance of estimate 
calculations, preparation of settlement material and preparation of internal and 
external correspondence. Additionally, a method of processing an insurance claim 
has been described that permits a user or users to create an insurance workfile and 
transfer all or part of the workfile over a network between computers at various 
locations where additional administrative or calculation steps may be performed 
and appended to the workfile. 

Applicant's claims are directed to a method of processing transactions between two or more 
trading partners without the requirement of the trading partners using the same software. 
Applicant's method provides the interface that allows a transaction to be performed. 

Applicant's claimed method is directed to a combination of features including the feature 
of "automatically reading additional information from an administration system in data 
communication with a computer system." Applicant submits that this feature, in combination 
with the other features of Applicant's claims, is not taught or suggested by the cited art. 
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Borghesi appears to teach the use of a common datafile for processing of claims. Information 
may be added to the datafile by various users of the software application. For example, Borghesi 
states: 

After creating or editing vehicle data, the user can go into the estimate tab of the 
workfile to create or edit an estimate. As shown in FIG. 8G, a user can either 
change estimate lines within the estimate 232, identify other charges such as 
towing or storage fees 234, or simply review the estimate totals for the car 236. 
When a user is editing or adding information to the estimate, several databases are 
accessed automatically. Preferably, these databases are stored in a memory device 
such as a hard drive attached to the computer a user is using. 
(Borghesi, col. 12, lines 37-46) 

Borghesi appears to teach that various databases are accessed while data is being entered. The 
databases appear to be accessed to allow the user to select additional information to be entered 
into the datafile regarding the claim. Applicant's claims, however, relate to a different kind of 
use of databases. Upon submission of a transaction to Applicant's software, the software 
automatically finds additional information and adds the information to the transaction 
information without the need for a user to make selections. Applicant submits that this type of 
automated processing is not taught or suggested by Borghesi. It should be further noted that this 
type of processing is not simply a translation of one data format into another data format, such as 
taught in Richards. Instead, Applicant's claimed method not only translates the data to a form 
that is readable by the receiving partner's software, but automatically adds any additional 
information needed to process the transaction to the outgoing transaction. 

Applicant's claimed method is further directed to a combination of features including the 
feature of "generating at least one outgoing transaction in response to reading the additional 
information from the administration system, wherein at least one outgoing transaction comprises 
data from the incoming transaction and the additional information read from the administration 
system." Applicant submits that this feature does not appear to be taught or suggested by 
Borghesi. Borghesi teaches that: 
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Within the total loss valuation tab of the user interface a user can access entry 
fields to organize a valuation request. The steps a user takes in creating and 
viewing total loss calculations are shown in FIG. 8J. Within totals tab of the user 
interface, a user can create 268 a valuation request including all the pertinent 
information a third party database company needs to create the specific total loss 
valuation. After entering all the necessary data, a user then submits a valuation 
request 270 for completion. The valuation request is preferably transferred 272 to 
the outbox where it will be sent out over the system described above to be handled 
by a third party service provider. Total valuation results are received over the 
same communication network in the in box for the user and may be reviewed 274 
by the user after accessing the in box and merging the data in the claimed datafile. 
The presently preferred method saves a user time by automatically transferring all 
files, whether from the out box or to the in box, when the user connects to the 
communications server via modem. 
(Borghesi, col. 13, 1. 41-60) 

Borghesi appears to teach that a user of the software will request information from an outside 
source for use in processing a claim. Once received, the user will add the information to the 
datafile. After this information is added to the datafile, by the user, the datafile may be accessed 
by another user to continue processing of the transaction. 

Applicant's claims are directed to a method of automatically processing claims. For example, 
Applicant's specification states: 

In step 902, in response to receiving the incoming transaction from the at least one 
sending trading partner, additional information is read, obtained, or otherwise 
extracted from an administration system in order to complete the processing of the 
transaction. 

(Specification, page 22, lines 8-11) 

An outgoing transaction is generated in response to obtaining additional 
information from an administration system. The outgoing transaction may include 
the additional data obtained from the administration system. 
(Specification, page 22, lines 23-25) 

Applicant submits that Borghesi does not appear to teach or suggest the features of Applicant's 
claims. Furthermore, Applicant submits that the combination of Borghesi with DiRienzo does 
not appear to teach or suggest the combination of features of Applicant's claim 1. 
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The Examiner states: 

Regarding claim 10, DiRienzo further discloses the computer system 
sending the outgoing transaction to the at least one receiving trading partner 
through an industry clearinghouse system (see figure 6A, the provider send the 
outgoing transaction to the clearinghouse system). Therefore, it would have 
been obvious to one with ordinary skill in the art at the time the invention was 
made to combine the feature above with Borghesi' s for the purpose of providing 
the clearinghouse system as an intermediate between trading partners, servers as 
an electronic routing system for the claims and checks to determine if the 
information is complete. 

Claim 10 describes a combination of features including: "wherein sending at least one 
outgoing transaction to at least one receiving trading partner further comprises sending at least 
one outgoing transaction to at least one receiving trading partner through an industry 
clearinghouse system." Applicant submits, for at least the reasons cited above, that the features 
of claim 10 are not taught or suggested by Borghesi in view of DiRienzo and further in view of 
Richards. Applicant respectfully requests removal of the rejection of claim 10. 

The Examiner states: 



Regarding claims 52-56, Borghesi further discloses at least one business rule comprises: 
a receiving trading partner identifier, and administration system identifier, a transaction 
identifier, a transaction status, a sending trading partner identifier (column 9, lines 18-32). 

Claim 53 describes a combination of features including: "wherein at least one business 
rule comprises an administration system identifier." Claim 54 describes a combination of 
features including: "wherein at least one business rule comprises a transaction identifier." Claim 
55 describes a combination of features including: "wherein at least one business rule comprises a 
transaction status." 



Borghesi states: 
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Administrative information stored in the 'ADMIN' tab includes several 
frames 108 of information accessible through the frame switching button bar 
106 inside the tab. Preferably, the information comprises assignment 
information, inspection information, policy information, party information, 
statements, loss information, and repair site information. Assignment 
information includes items such as the claim number, the date the claim was 
reported, the date the claim was assigned, and information on who received the 
assigned claim, e.g., the names of the insurance company, appraiser and 
adjuster, as well as claim office location. (Borghesi, column 9, lines 18-29) 

Applicant submits that the information in the ADMIN tab of Borghesi does not include an 
administration system identifier, a transaction identifier, or a transaction status. Applicant 
respectfully requests removal of the rejections of claims 53, 54, and 55. 

The Examiner states: "Regarding claim 57, Borghesi further discloses the business rule is 
entered into a database (column 12, lines 14-22). 

Claim 57 describes a combination of features including: "wherein at least one business 
rule is entered into a database." Borghesi appears to teach accessing a database. For example, 
Borghesi states: 

After entering the vehicle identification data, the system automatically selects a 
database 222 from which to access parts lists and values for the particular 
vehicle. Within the database a search may be made by year, make and model of 
the vehicle 224 or the user may decide to have the vehicle identification number 
(VIN) decoded 226 in the database. (Borghesi, column 12, lines 19-22) 

When a user is editing or adding information to the estimate several databases 
are accessed automatically. Preferably, these databases are stored in a memory 
device such as a hard drive attached to the computer a user is using. In one 
preferred embodiment the user may access an original equipment manufacturer 
(OEM) part database 238, a recycled part/salvage part database 240, a labor cost 
database 242 and an aftermarket part database 244. Suitable commercially 
available databases for these four databases are the MOTOR database put out by 
Hearst Corporation, the recycled part valuation (RPV) database of salvage parts 
compiled by CCC Information Services, Inc., developed by Hearst Corp, 
containing labor rates, and an aftermarket parts database compiled by CCC 
Information Services, Inc. (Borghesi, column 12, lines 42-57) 
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Applicant submits that Borghesi does not appear to teach or suggest at least one business rule 
entered into a database. Applicant respectfully requests removal of the rejection of claim 57. 

The Examiner states: "Regarding claim 13, claim 13 contains similar limitations found in 
claim 1 above, and is rejected by the same rationale." 

Amended claim 13 describes a combination of features including: 

store a trading relationship between trading partners of a transaction, wherein the 
trading relationship is stored in the database, wherein at least one trading partner 
is a sending trading partner and at least one trading partner is a receiving trading 
partner; 

receive at least one incoming transaction from the at least one sending trading 
partner; 

automatically read additional information from the administration system in 
response to receiving at least one incoming transaction from at least one sending 
trading partner, wherein the additional information is identified by at least one 
business rule; 

generate at least one outgoing transaction in response to reading the additional 
information from the administration system, wherein at least one outgoing 
transaction comprises data from the incoming transaction and the additional 
information read from the administrative system; 

translate at least one outgoing transaction into a format readable by a receiving 
trading partner; and 

send at least one outgoing transaction to at least one receiving trading partner, 
wherein at least one receiving trading partner is identified in the trading 
relationship. 

Applicant submits, for at least the reasons cited above, that the features of claim 13 are 
not taught or suggested by Borghesi in view of DiRienzo and further in view of Richards. 
Applicant respectfully requests removal of the rejection of claim 13 and the claims dependent 
thereon. 
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The Examiner states: "Claims 18-22, 28, 32-34, 36, 38, 58-62 are written in computer 
software that parallel limitations found in claims 1-4, 57, 5-8, 10, 12, 52-56 as discussed above, 
therefore, are rejected by the same rationale." 

Amended claim 18 describes a combination of features including: 

receiving at least one incoming transaction from at least one sending trading partner, 

reading additional information from an administration system in response to receiving the 
incoming transaction from the at least one sending trading partner, wherein the additional 
information is identified by at least one business rule; 

automatically generating at least one outgoing transaction in response to reading the 
additional information from the administration system, wherein at least one outgoing 
transaction comprises data from the incoming transaction and at least a portion of the 
additional information read from the administrative system; 

translating at least one outgoing transaction into a format readable by a receiving trading 
partner; and 

sending at least one outgoing transaction to at least one receiving trading partner. 

Applicant submits, for at least the reasons cited above, that the features of claim 18 are 
not taught or suggested by Borghesi in view of DiRienzo and further in view of Richards. 
Applicant respectfully requests removal of the rejection of claim 18 and the claims dependent 
thereon. 

Claim 22 describes a combination of features including: "wherein at least one business 
rule is stored in a database." Applicant submits, for at least the reasons cited above, that the 
features of claim 22 are not taught or suggested by Borghesi in view of DiRienzo and further in 
view of Richards. Applicant respectfully requests removal of the rejection of claim 22. 

Claim 36 describes a combination of features including: "wherein at least one outgoing 
transaction is sent to the at least one receiving trading partner through an industry clearinghouse." 
Applicant submits, for at least the reasons cited above, that the features of claim 36 are not 
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taught or suggested by Borghesi in view of DiRienzo and further in view of Richards. Applicant 
respectfully requests removal of the rejection of claim 36. 

Claim 59 describes a combination of features including: "wherein at least one business 
rule comprises an administration system identifier." Claim 60 describes a combination of 
features including: "wherein at least one business rule comprises a transaction identifier." Claim 
61 describes a combination of features including: "wherein at least one business rule comprises a 
transaction status." Applicant submits, for at least the reasons cited above, that the features of 
claims 59-61 are not taught or suggested by Borghesi in view of DiRienzo and further in view of 
Richards. Applicant respectfully requests removal of the rejections of claims 59-61. 

The Examiner states: 

Regarding claims 39-44, Borghesi further the outgoing transaction is an 
insurance-related transaction, an annuity asset pricing transaction, a positions 
and valuation focused refresh transaction, an insurance pricing transaction, a 
commission settlement transaction (column 4, lines 25-30, column 13, lines 45- 
53, column 10, lines 25-28, and column 16, lines 12-15). 

Claim 40 describes a combination of features including: "wherein at least one outgoing 
transaction is an annuity asset pricing transaction." Claim 41 describes a combination of features 
including: "wherein at least one outgoing transaction is a positions and valuation focused refresh 
transaction." Claim 42 describes a combination of features including: "wherein at least one 
outgoing transaction is a positions and valuation full refresh transaction." Claim 43 describes a 
combination of features including: "wherein at least one outgoing transaction is an insurance 
pricing transaction." Claim 44 describes a combination of features including: "wherein at least 
one outgoing transaction is a commission settlement transaction." 

Borghesi teaches various transactions. For example, Borghesi states: 

Within totals tab of the user interface, a user can create 268 a valuation request 
including all the pertinent information a third party database company needs to 
create the specific total loss valuation. (Borghesi, column 13, lines 45-48) 
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At this point, the user may send out a request for a specific total loss valuation 
from a third party provider that will calculate the specific value of the car. 
(Borghesi, column 10, lines 25-27) 

The body shop then creates 404 a computer Estimate-Of-Record (EOR) and e- 
mails via the out box, as part of a work file, the EOR and electronic images to 
the insurance company. (Borghesi, column 16, lines 12-15) 

Applicant submits that the total loss valuation and Estimate-Of-Record of Borghesi do 
not correspond to an annuity asset pricing transaction, a positions and valuation focused refresh 
transaction, a valuation full refresh transaction, an insurance pricing transaction, or a commission 
settlement transaction. Applicant respectfully requests removal of the rejections of claims 40-44. 

The Examiner states: "Claims 47-51 are written in computer software that parallel 
limitations found in claims 13, 14, 57, 12, 46 discussed above, therefore are rejected by the same 
rationale." 



Amended claim 47 describes a combination of features including: 

storing a trading relationship between trading partners of a transaction, wherein at least 
one trading partner is a sending trading partner and at least one trading partner is a 
receiving trading partner; 

receiving at least one incoming transaction from at least one sending trading partner, 

reading additional information from an administration system in response to receiving the 
incoming transaction from the at least one sending trading partner, wherein the additional 
information obtained is identified by at least one business rule; 

automatically generating at least one outgoing transaction in response to reading 
additional information from the administration system, wherein at least one outgoing 
transaction comprises data from the incoming transaction and the additional information 
read from the administrative system; 

translating at least one outgoing transaction into a format readable by a receiving trading 
partner; and 

sending at least one outgoing transaction to the at least one receiving trading partner, 
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wherein the at least one receiving trading partner is identified in the trading relationship. 

Applicant submits, for at least the reasons cited above, that the features of claim 47 are 
not taught or suggested by Borghesi in view of DiRienzo and further in view of Richards. 
Applicant respectfully requests removal of the rejection of claim 47 and the claims dependent 
thereon. 

Claim 49 describes a combination of features including: "wherein at least one business 
rule is stored in a database." Applicant submits, for at least the reasons cited above, that the 
features of claim 49 are not taught or suggested by Borghesi in view of DiRienzo and further in 
view of Richards. Applicant respectfully requests removal of the rejection of claim 49. 

The Examiner states: 

Regarding to claims 63-70, DiRienzo discloses the industry clearinghouse 
system comprises an insurance industry clearinghouse system, an insurance 
annuity clearinghouse system (see figure 6A and column 17, lines 41-53). 
Therefore, it would have been obvious to one with ordinary skill in the art at the 
time the invention was made to combine the feature above with Borghesi' s for 
the purpose of providing the clearinghouse system as an intermediate between 
trading partners, servers as an electronic routing system for the claims and 
checks to determine if the information is completed. 

Claims 63, 65, 67, and 69 describe a combination of features including: "wherein the 
industry clearinghouse system comprises an insurance industry clearinghouse system." Claims 
64, 66, 68, and 70 describe a combination of features including: "wherein the industry 
clearinghouse system comprises an insurance annuity clearinghouse system." Applicant submits, 
for at least the reasons cited above, that the features of claims 63-70 are not taught or suggested 
by Borghesi in view of DiRienzo and further in view of Richards. Applicant respectfully 
requests removal of the rejections of claims 63-70. 

C. The Claims Are Not Obvious Over Borghesi In View of DeRienzo and Further In 
View of Richards and Wamslev Pursuant To 35 U.S.C. § 103(a) 
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The Examiner rejected claims 29-31 under 35 U.S.C. 103(a) as obvious over Borghesi in 
view of DiRienzo and further in view of Richards and U.S. Patent No. 5,956,687 to Wamsley et 
al. (hereinafter "Wamsley"). Applicant respectfully disagrees with these rejections. 

The Examiner states: 

Regarding claims 29-31, Borghesi, DiRienzo, and Richards do not teach 
the computer system implements storing a schedule in memory, wherein the 
schedule relates to the incoming transaction, and wherein the schedule 
comprises: a predetermined time for receiving the incoming transaction from the 
at least one sending trading partner, a predetermined time for reading the 
additional information from the administration system, a predetermined time for 
sending the outgoing transaction to the at least one receiving trading partner. 
Wamsley teaches such feature above (see column 32, line 49-column 33, line 
20). Therefore, it would have been obvious to one with ordinary skill in the art 
at the time of the invention was made to include the feature above with 
Borghesi' s for the purpose of providing more convenient for the user to 
receiving an incoming transaction at a specified date and time. 

Claim 29 describes a combination of features including: "wherein the program 
instructions are further executable by the computer system to implement storing a schedule in 
memory, wherein the schedule relates to at least one incoming transaction, and wherein the 
schedule comprises a predetermined time for receiving at least one incoming transaction from the 
at least one sending trading partner." 

Claim 30 describes a combination of features including: "wherein the program 
instructions are further executable by the computer system to implement storing a schedule in 
memory, wherein the schedule relates to at least one incoming transaction, and wherein the 
schedule comprises a predetermined time for reading the additional information from the 
administration system." 

Claim 31 describes a combination of features including: "wherein the program 
instructions are further executable by the computer system to implement storing a schedule in 
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memory, wherein the schedule relates to at least one outgoing transaction, and wherein the 
schedule comprises a predetermined time for sending at least one outgoing transaction to the at 
least one receiving trading partner." 

Wamsley appears to teach date driven reminders. For example, Wamsley states: 

Button icon 170f corresponds to date driven reminders or 'ticklers' 
generated by a program. Generally, these ticklers are text reminders inserted 
into appropriate reports and worksheets and selectively presented with display 
52. Ticklers prompt the operator to take a designated action on a predetermined 
date. (Wamsley, column 13, lines 62-67) 

Applicant submits that the "reminders" of Wamsley do not describe a schedule 
comprising a predetermined time for receiving at least one incoming transaction from the at least 
one sending trading partner, a schedule comprising a predetermined time for reading the 
additional information from the administration system, or a schedule comprising a predetermined 
time for sending at least one outgoing transaction to the at least one receiving trading partner. 
Applicant respectfully requests removal of the rejections of claims 29-31. 

D. Summary 

Based on the above, Applicant submits that all claims are in condition for allowance. 
Favorable reconsideration is respectfully requested. 
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